1. Field of the Invention
The present invention relates generally to analyzing software performance, and more particularly, to a system, method, and program for analyzing code execution in order to analyze and improve software performance by rapidly identifying of areas of code based on cost and use, and which may be candidates for optimization.
2. Related Art
Performance is an important aspect of software design. If an application does not perform well, users will not likely want to use that application. Performance is a subjective term referring to the general way in which something operates. Performance may include how efficiently system resources (e.g., CPU, memory, and hard disk drive) are used. There are aspects of performance, including but not limited to speed, memory footprint, memory turnover, memory usage, file-system usage, etc., that can be measured. Improving on these measurements increases the efficiency of the software.
The reason for poor performance of a software program is not always apparent. In particular, large-scale software can be extremely complex, with multiple layers and many modules, such that implementation details (those causing performance problems) are often hidden across layers and modules.
Software programs can be “sampled” when various events occur at runtime. Samples may be taken, for example, at a specified time interval (time-based sampling). When a sample is taken, the program's stack backtrace and other information can be recorded, and entered into a “trace table.” A trace table may have many thousands of such entries, depending on how many samples were taken.
When a sampling run is complete, the trace table can be analyzed to build a single function call tree, showing the full tree of all function calls that were made, from the application's main entry point to the lowest leaf function. That “top-down” function call tree can be navigated to see the pattern of function calls in the application, to see overall how resources were used by the application. It is difficult, however, to see all the ways that a particular “leaf” function (i.e., a terminal function with no children) was reached, since that leaf function may appear at the ends of many different branches of the function call tree.
A function call tree can be “inverted” to create a list of all leaf function calls, and for each such call, a “bottom-up” function call tree of all the ways that the leaf function call was reached can be shown. In many cases, however, the leaf function calls are system-level functions that are not interesting to the programmer.